Pull request overview

This PR enables propagation of user defined FunctionResult.Metadata created or modified in auto function invocation filters into the ChatHistory tool message metadata, making it accessible to downstream consumers like OrchestrationResponseCallback.

Changes:

• Populate ChatMessageContent.Metadata for tool messages with AutoFunctionInvocationContext.Result.Metadata when adding function results to chat history.
• Add a unit test validating metadata flow from a filter set FunctionResult.Metadata to the resulting tool ChatMessageContent.Metadata.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Automated Code Review

Reviewers: 4 | Confidence: 91%

✓ Correctness

This PR propagates FunctionResult.Metadata to the ChatMessageContent added to chat history after function call execution. The implementation accesses resultContext.Context.Result.Metadata to pass as the metadata parameter to the ChatMessageContent constructor. The code is correct: Result is a non-nullable property on AutoFunctionInvocationContext (always initialized), Metadata is nullable IReadOnlyDictionary which the ChatMessageContent constructor accepts as nullable, and the test properly validates the round-trip through a filter that sets metadata on the FunctionResult. The change is minimal and well-tested.

✓ Security Reliability

This PR propagates FunctionResult.Metadata from function invocation results to the ChatMessageContent added to chat history. The change is minimal and safe. The metadata parameter on the ChatMessageContent constructor is nullable (IReadOnlyDictionary<string, object?>?), so null metadata in the error path (when ExecuteFunctionCallAsync catches an exception and the FunctionResult retains its initial null metadata) is handled gracefully. No injection risks, resource leaks, or unsafe deserialization are introduced. The metadata is user-controlled (set by function implementations or auto-invocation filters), so propagating it to chat history is an intentional and appropriate design choice. The test adequately verifies the new behavior by exercising a filter that sets custom metadata and asserting it appears on the tool message.

✓ Test Coverage

The PR adds metadata propagation from FunctionResult to ChatMessageContent in the tool message added to chat history. The test covers the key scenario where a filter sets metadata on the FunctionResult and verifies it appears on the resulting ChatMessageContent. The test is well-structured with meaningful assertions. However, there are two missing edge-case tests: (1) the default case where no filter modifies metadata (metadata should be null), and (2) the error/exception path where AddFunctionCallResultToChatHistory is also called but the FunctionResult has no metadata. These are not blocking since the null-metadata case is implicitly covered by all existing tests that don't set metadata, but an explicit null-metadata assertion would strengthen confidence.

✗ Design Approach

The single-line change propagates FunctionResult.Metadata to the ChatMessageContent that wraps the tool response, which is the intended behavior. However, the implementation has a subtle design flaw: by passing metadata to the ChatMessageContent constructor together with content, the metadata is inadvertently copied into the auto-created TextContent item inside Items. This happens because the Content property setter (called from the constructor after this.Metadata is already set) creates a new TextContent(metadata: this.Metadata). As a result, the function result metadata ends up on both message.Metadata and message.Items[0] (the TextContent), but not on message.Items[1] (the FunctionResultContent), which is the semantically correct carrier for function-invocation metadata. The fix is simple: construct the message without metadata (so the TextContent is created with null metadata), then assign message.Metadata separately. The test is well-structured and validates the right observable behavior.

Flagged Issues

• Passing metadata in the ChatMessageContent constructor causes the same metadata dictionary to be copied into the auto-created TextContent item (via the Content setter's new TextContent(metadata: this.Metadata) path). Function-result metadata is semantically tied to the function invocation, not to a text representation item. The correct approach is to set message.Metadata after construction, so the TextContent stays metadata-free while the message-level metadata still propagates correctly.

Suggestions

• Consider adding a test for the error/exception path (function throws) to verify that AddFunctionCallResultToChatHistory does not surface unexpected metadata on the tool message—currently the error path still flows through this method and will propagate whatever metadata exists on the FunctionResult at the time of failure.
• Consider adding a test that verifies ChatMessageContent.Metadata is null when no filter modifies the FunctionResult metadata (the default path), ensuring the change doesn't accidentally introduce non-null metadata where none existed before.

Automated review by gmtorres's agents